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Basic Authorization Code 


Basic Authorization Code (BAUT) (package 25) provides for up to 4096 
authorization codes of 1 to 14 digits. Users can enter an authorization code 
after dialing the Special Prefix (SPRE) and the digit “6” before dialing any 
call, including a Network Alternate Route Selection (NARS), Basic Alternate 
Route Selection (BARS), or Coordinated Dialing Plan (CDP) call. With the 
BAUT feature, an authorization code can be entered when doing the 
following: 


— originating a call from a local station or tie trunk 
— initiating a call transfer or conference from a local station 


— originating a call via the Direct Inward System Access (DISA) feature 


Note: Refer to Basic and Network Alternate Route Selection description 
(553-275 1-100) for a description of the NARS and BARS features. Refer 
to Coordinated Dialing Plan description (553-275 1-102) for a 
description of the CDP feature. 


Authorization code validation 


The software validates an entered authorization code on the basis of the 
number of digits dialed and the dialed digits themselves. If the number of 
digits in the entered authorization code does not match the defined 
authorization code length (authorization code Data Block, AUB, LD 88), the 
authorization code is deemed invalid. Similarly, if the dialed authorization 
code digits are not defined in the authorization code table (AUT, LD 88), the 
authorization code is deemed invalid. 


Basic and Network Authorization Code Description 
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Feature description 


When an invalid authorization code is encountered, no response is given to the 
user until the End-of-Dialing (EOD) timer expires. (This increases the security of 
authorization codes by making it difficult for an unauthorized user to determine 
the length of a valid authorization code.) When the EOD timer expires, overflow 
tone is given for 15 seconds and the call is forcibly disconnected. 


Station Specific Authcode 


With X11 release 19 and later, Station Specific Authcode (SSAU), package 
229, enables the system administrator to define the authorization code access 
level for each telephone. This feature applies to 500/2500 and digital 
telephones and is implemented on a per telephone basis. It does not apply to 
BRI telephones. 


Station Specific Authcode provides three levels of authorization code access: 


1 AUThcode Unrestricted (AUTU) 
A telephone configured as AUTU has no authorization code access 
limitations. 


2  AUThcode Restricted (AUTR) 
A telephone configured as AUTR can enter up to six assigned 
authorization codes. (The same authorization code may be assigned to 
more than one AUTR telephone.) 


3 AUThcode Denied (AUTD) 
A telephone configured as AUTD has no access to authorization codes. 
Any authorization code entered will be rejected, and the call will not be 
completed. 


Operating parameters 


The same authorization code may be assigned to more than one AUTR 
telephone. 


There is cross-checking between LD 10 and LD 11, which define a station 
specific authorization code, and LD 88, which ensures that the user has 
entered a valid authorization code. 


LD 88, which deletes an existing authorization code, does not check if the 
authorization code is assigned as a station specific authorization code before 
the deletion. 


Attendant Administration does not support the assignment of Station Specific 
Authcode. 
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Feature operation 

After an authorization code is entered, the Station Specific Authcode feature 
determines if the telephone is allowed to use the entered code. If the 
authorization code is not allowed on that telephone, the existing invalid 
authorization code treatment occurs. Otherwise, normal authorization code 
processing occurs. 


Authcode security enhancements 


The Authorization Code Security Enhancements feature enables a user to 
temporarily override the access restrictions assigned to a station or trunk 
because of their assigned Network Class of Service (NCOS), Class of Service 
(COS), and Trunk Group Access Restrictions (TGAR) codes. If a user 
requires access to system facilities in addition to that allowed on the set, the 
Authcode feature can be used to provide them. 


The Authorization Code (Authcode) Alarm feature alerts the technician when 
an invalid Authcode is entered by generating an Authcode Alarm. The Alarm 
indicates to the technician that some unauthorized person may be trying to use 
an Authcode to illegally access the switch. 


The Authcode alarm is generated upon detection of violation of all Authcode 
related features (i.e., Basic Network, and Station Specific Authorization code 
features), except for calls originated by the attendant. 


A new class of alarm has been added (Security Administration - SECA) to 
distinguish security violations from other types of system messages. The 
message SECA0001 will be printed on the TTY. 


Basic and Network Authorization Code Description 


Page 6 of 78 


Feature description 


Operating parameters 
This feature is enabled through the Authcode data block in LD88. 


The Authcode Alarm feature does not apply to calls originated by an 
attendant. 


All existing operating parameters relating to Authorization Code usage apply 
to this feature. 


All existing operating parameters relating to Fault Management apply to this 
feature. 


For security reasons, the SECA0001 alarm should not be configured in the 
Exception Filter table. 


Feature interactions 

Authorization Code Features A Security Administration (SECA) 
message will be printed to the configured Maintenance Terminal (MTC), 
Filtered Alarm Output (FIL) console and/or the configured History File when 
an invalid Authcode is detected. The following features relate to 
Authorization Codes and are thus impacted: Basic Authorization Codes; 
Network Authorization Codes; Authcode Conditionally Last; Direct Inward 
System Access with Authorization Code; Station Specific Authcode; Speed 
Call/Autodial with Authorization Codes; Call Forward with Authorization 
Codes; Scheduled Access Restrictions with Authorization Codes; 
Coordinated Dialing Plan with Authorization Codes; and Flexible Feature 
Code with Authorization Codes. 


Direct Private Network Access with Authorization Code Retry Only 
when an Authcode retry fails will a SECA message be printed to the 
configured MTC, FIL console and/or the configured History File. 
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Feature packaging 
This feature is part of base X11 system software. 


The following software packages are optional, but may be needed depending 
upon the application: 


— Meridian 1 Alarm Filter (ALRM_FILTER) package 243 
— Basic Authorization Code (BAUT) package 25 

— Basic Alternate Route Selection (BARS) package 57 
— Network Alternate Route Selection (NARS) package 58 
— Coordinated Dialing Plan (CDP) package 59 

— Direct Private Network Access (DPNA) package 250 
— Direct Inward system Access (DISA) package 22 

— Network Class of Service (NCOS) package 32 

— Network Authorization Code (NAUT) package 63 

— Station Specific Authcodes (SSAU) package 229 

— Recorded Announcement (RAN) package 7 

— Scheduled Access Restrictions (SAR) package 162, and 


— System Speed Call (SSC) package 34, or Network Speed Call (NSC) 
package 39. 


Basic and Network Authorization Code Description 
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Feature implementation: 
LD 88—Configure the Authcode Alarm for each customer 
REQ NEW CHG Configure or change. 
TYPE AUB Authcode Data Block. 
CUST 0-99 Customer number. 
SPWD XXX Secure data password. 
ALEN Number of digits in Authcode. 
ACDR (Do not) activate CDR for authcodes. 


AUTHCOD_ALRM (Disable) enable Authcode Alarm. 





LD 17—Configure the Alarm Filter table as per existing configuration 
procedures. The Authcode alarm must be configured in this table in order for 
the messages to be displayed on the FIL TTY. 


Feature operation 
No specific operating instructions are required to use this feature. 
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Collect Call Blocking(Brazil) 


In Brazil an automatic long distance collect call service called DDC is 
available. The collect Call Blocking feature enables a Meridian 1 
administrator to block DDC calls on incoming Direct Inward dialing (DID) 
and Public Exchange/Control Office trunks (analog or DT 12). Under the 
following conditions, the Meridian 1 sends a special answer signal to the 
Central Office that collect calls cannot be accepted: 


— The Collect Call Blocking (CCB) package 290 is enabled 


— The incoming route has CCB enabled via the CCB prompt in the Route 
Data Block, and 


— The call is answered by a CCB user (i.e., Collect Call Blocking Allowed 
Class of Service or option). 


New Classes of Service and prompts have been introduced to inhibit specific 
users fro receiving collect DID and Central Office calls. These can be 
configured for the following: 


— PBX and BCS through the Collect Call Blocking Allowed/Denied 
(CCBA/CCBD) Class of Service. 


— Attendant and Network Alternate Route Selection calls on a per 
customer basis through CCBA/CCBD option. 


— Automatic Call Distribution (ACD) queues through the CCBA prompt. 
— Direct Inward system Access (DISA) through the CCBA prompt. 


— Tandem calls dialed with Coordinated Dialing Plan (CDP) (Trunk 
Steering Code, Distant Steering Code) through the CCBA prompt. 


— Tandem non-CDP calls through the CCBA prompt in the Route Data 
Block from the outgoing trunk route. 


The Meridian 1 sends the CCB answer signal in place of the regular signal for 
incoming DID/CO calls from routes with CCB enabled, when a call is 
answered by a CCB user. If the call is a collect call, the CO will disconnect 
the call. 


Basic and Network Authorization Code Description 
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Feature description 


Operating parameters 


The Collect Call Blocking feature supports both analog and DT 12 trunks, and 
the following Intelligent Peripheral Equipment (IPE) cards: 


— The NTCK 16BB Extended Flexible COT Trunk Card (XFCOT) with 
firmware flash timing 


— The NT8D14BA Enhanced Extended Universal Trunk Card (EXUT) 
containing the Centrex Switchhook Flash function in the firmware, and 


— The NT8K14AK Extended Universal Trunk Card (XUT) which may be 
used if the Centrex Switchhook Flash is configured with software timing. 


— The Collect Call Blocking answer signal can only be sent in cases where 
answer supervision is provided by the Meridian 1. 


Once the modified answer signal is sent to the CO, the Meridian 1 has no 
control over how the call will be handled by the CO. 


Ifa CCB user answers a call from a CO/DID route with Collect Call Blocking 
activated, the CCB answer signal is sent to the CO for all incoming DID and 
CO calls. For analog trunks, the user will experience clicking on the line and 
a temporary break is speechpath (0.5 to 2.5 seconds) while the CCB answer 
signal is being sent. 


If the XFCOT and EXUT cards do not have flexible firmware timing, the 
CCB flash portion of the CCB answer signal will be returned to the CO. 
However, software controlled signaling can be done with EXUT cards. 


In a standalone environment, all input from a set (except from the Release 
key) is ignored while the Collect Call Blocking answer signal is being sent. 


Collect Call Blocking is applied to attendants on a customer basis only; it 
cannot be applied on a tenant basis. 


The answer signal returned for a call from a route with CCB enabled and that 
is Network Attendant Service (NAS) routed is determined by the customer 
option on the source node. Thus, NAS routing can be configured across any 
Meridian Customer Defined Network environment, but the source node 
determines the answer supervision sent to the CO. 
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Call Detail Recording (CDR) record timing begins on the first answer of the 
CCB answer sequence. For this reason, CDR records will be generated for 
incoming calls to CCB users across routes on which CCB is enabled. If the 
call is collect, and is dropped, a CDR record of approximately CCB1 + CCB2 
length will be generated. 


For data calls all calls will be answered with the CCB answer signal, if CCB 
is enabled. This may have an effect on data protocols, while CCB signaling 
is taking place. 


If firmware timing is used (FWTM = YES in LD 14) for sending the CCB 
flash, the CCB2 timer is downloaded to the card before sending the firmware 
flash. If the CCB2 timer is changed in the Route Data Block, either the card 
has to be enabled or the switch has to be initialized to get the new CCB2 timer 
downloaded to the card. 


Feature interactions 

Automatic Answerback The Automatic Answerback (AAB) feature, when 
assigned to a BCS set, allows any incoming N) to be answered automatically. 
If an incoming DID or CO call terminates on a set with the AAB feature 
enabled, the call is automatically answered after one ring. If the set has a 
CCBA Class of Service, the CCB answer signal is provided in the place of the 
regular answer signal. 


Automatic Call Distribution Collect Call Blocking can be enabled on an 
ACD queue basis. Hence, if an incoming CO or DID call is answered by an 
ACD agent, the answer supervision signal that is returned to the CO is 
determined by the value of the CCBA prompt in LD 23. While the CCB 
answer signal is being sent, the same limitations apply to ACD as apply to sets 
with CCBA Class of Service. 


Automatic Call Distribution Interflow If an ACD call from a route with 
CCB enabled is diverted to an interflow DN, and answer supervision has not 
already been provided, the answer signal returned to the CO depends on the 
source ACD queue. The CCB answer signal is returned to the CO if the source 
ACD queue has CCB enabled. 


Basic and Network Authorization Code Description 
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Automatic Call Distribution Night Call Forward If an ACD call froma 
route with CCB enabled is diverted to a Night Call Forward DN, and answer 
supervision has not already been provided, the answer supervision signal 
returned to the CO depends on the source ACD queue. The CCB answer 
signal is returned to the CO if the source ACD queue has CCB enabled. 


Automatic Call Distribution Night RAN Route Announcement If an 
ACD call from a route with CCB enabled is diverted to a Night RAN route 
(defined by NRRT in the ACD block), the CCB signal returned to the CO 
depends on the source ACD queue. If the source ACD queue has CCB 
enabled, the CCB answer signal is sent to the CO. 


Autoterminate If an incoming DID or CO call from an autoterminate trunk 
terminates on a set or ACD queue with a CCBA Class of Service, the CCB 
answer signal is provided in place of the regular answer signal. 


Basic Rate Interface (BRI) Sets 

For BRI sets CCBA/CCBD Class of Service cannot be programmed. 
Therefore, it is not possible to prevent BRI sets from accepting DDC collect 
calls. 


Central Answering Position (CAP) The answer signal returned to the CO 
for calls that get answered by a Central Answering Position (CAP) is 
determined by the source ACD configuration and not the customer option 
(CCBA/CCBD in LD 15) on the source node. 


Centralized Attendant Service The answer signal returned to the CO for 
calls that get answered by a Centralized Attendant Service is determined by 
the customer option (CCBA/CCDB in LD 15) on the source node. 


Centrex Switchhook Flash A Centrex Switchhook Flash cannot be 
invoked by another feature while the CCB answer signal is being sent. 


Enhanced Malicious Call Trace Ifa station activates Malicious Call Trace 
(MCT) while the CCB answer signal is being sent, MCT activation is ignored. 
This also applies to the case when MCT is activated from a remote node. 
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Meridian Mail Because Meridian Mail is configured using ACD queues, the 
same interactions exist as in the ACD case. When Meridian Mail sends a call 
answer message to the Meridian 1, the CCB configuration in the source ACD 
queue is used to determine if a CCB answer signal should be sent to the 
Central Office. All mail boxes using the same ACD queue to access Meridian 
Mail will get the same CCB treatment. 


If some of the mail boxes are allowed to receive collect calls, this may be a 
problem. A possible solution is to configure two ACD queues on the 
Meridian | to access Meridian Mail. One queue would have collect calls 
allowed (i.e.e, CCBA = NO) and the second queue would have collect calls 
denied (i.e.e, CCBA = YES). 


Network Automatic Call Distribution The answer signal returned to the 
CO for a network ACD call from a route with CCB enabled is determined by 
the source ACD queue. If the source ACD queue has CCB enabled, the CCB 
answer signal is returned in place of the regular answer signal. 


Pilot DN Ifan incoming DID or CO call has CCB enabled and is routed to 
a pilot DN, the answer signal returned to the CO is determined by the CCB 
configuration of the terminating station. 


Private Line Service If an incoming DID or CO call from a private line 
trunk terminates on a set with a CCBA Class of Service, the CCB answer 
signal is provided in place of the regular answer signal. 


Recorded Announcement (RAN) A RAN route is defined as having 
CCBA YES or NO, which is used if Coordinated Dialing Plan (CDP) or ACD 
queues were not used to get to the RAN route. If the call is routed through 
ACD/CDP to terminate on RAN, the CCB treatment will depend upon the 
CCB data of the ACD/CDP, and not the RAN route. 


Tandem to Unsupervised Trunk If an incoming DID or CO call tandems 
to an unsupervised trunk before it terminates, the answer signal is sent by 
time-out. Therefore, any CCB tandem calls made to unsupervised trunks will 
not have the CCB answer signal sent until the time-out occurs. 


Trunk Hook Flash (THF) Ifa station activates THF while the CCB answer 
signal is being sent, THF activation is ignored. 


Basic and Network Authorization Code Description 


Page 140f 78 Feature description 


Feature packaging 
Collect Call Blocking (CCB) package 290 must be provisioned to activate 
this feature. 


Feature implementation 
LD 16—Enable Collect Call Blocking on a route and configure timers. (Part 1 of 2) 
NEW CHG Add, or change. 
RDB Route Data Block. 
0-99 Customer number. 


0-511 Route Number. 
aaa Trunk type. Must be COT,DID,FEX, or WAT for CCB. 


M911_ANI M911 route. Must be set to NO to enable CCB. 


ISDN ISDN route. Must be set to NO to enable CCB. 


Incoming and outgoing 

Incoming 

Outgoing 

Must be either IAO or ICT to enable CCB. 


Must be either IAO or OGT to get the CCBA prompt for 
outgoing calls. 


Collect Call Blocking enabled or disabled on incoming 
route. CCB package 290 is required. Enter YES to 
obtain CCB timer prompts. 
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LD 16—Enable Collect Call Blocking on a route and configure timers. (Part 2 of 2) 


512-(1536)-4992 Collect Call Blocking delay timer 1 in milliseconds. 
Input rounded to the next multiple of 128 milliseconds. 


500-(1520)-2550 Collect Call Blocking delay timer 2 in milliseconds. 
Input rounded to the next multiple of 10 milliseconds. If 
any CCB route members (trunks) are using firmware 
timing (FWTM = YES in LD 14), changes to the CCB2 


timer value will not take effect until the new timer value 
is downloaded to the card. This can be done by 
enabling the card or initializing the switch. 


(NO) YES Collect Call Blocking allowed or denied for outgoing 
route. 





LD 14—Setup the firmware timing for XFCOT and EXUT cards. 


NEW CHG Add, or change. 

DID COT FEX WAT Trunk Type. 

Iscu Terminal Number. 

cu Terminal Number for the Option 11. 
ECUT XCOT Type of card. 


(NO) YES Firmware timing for flash. Enter YES to enable 
firmware timing. 


0-99 Customer number. 


XXX XXX Trunk route and member number. 





YES Answer supervision required. 
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LD 15—Add or change Collect Call Blocking for attendants. 


NEW CHG Add, or change. 


CDB Customer Data Block. 


0-99 Customer number. 


(NO) YES Centralized Attendant Service. 





(CCBD) CCBA (Deny) allow Collect Call Blocking. 


LD 10—Add or change Collect Call Blocking for PBX sets. 
NEW CHG Add, or change. 
500 Telephone type. 
Iscu Terminal Number. 


cu Terminal Number for the Option 11. 





(CCBD) CCBA (Deny) allow Collect Call Blocking. 


LD 11—Add or change Collect Call Blocking for BCS sets. 


NEW CHG Add, or change. 
aaaa Telephone type, where: 


aaaa = SL1, 2006, 2008, 2009, 2016, 2018, 2112, 
2216. 2317, 2616, or 3000. 


Terminal Number. 


Terminal Number for the Option 11. 


(CCBD) CCBA (Deny) allow Collect Call Blocking. 
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LD 23—Enable Collect Call Blocking on ACD queues. 


NEW CHG Add, or change. 


ACD ACD data block. 
0-99 Customer number. 


XXXX ACD Directory Number. 





(NO) YES (Deny) allow Collect Call Blocking. 


LD 24—Enable Collect Call Blocking on DISA blocks. 


NEW CHG Add, or change. 
DIS DISA data block. 
0-99 Customer number. 


XXXXXXX DISA Director Number. 


(NO) YES (Deny) allow CCB answer signal to be sent. 





LD 87—Enable Collect Call Blocking on CDP Steering codes. 


NEW CHG Add, or change. 
0-99 Customer number. 


CDP Coordinated Dialing Plan 


TSC DSC Steering code type. 





(NO) YES (Deny) allow CCB answer signal to be sent. 


Feature operation 
No specific operating instructions are required to use this feature. 
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Direct Private Network Access 


The Direct Private Network Access feature provides enhancements to the 
processing of Direct Inward System Access (DISA) and Authcode last 
request calls. This feature complements existing Meridian 1 capabilities to 
provide an arrangement suitable for long distance resellers. Typically, 
subscribers to these resellers” services dial in through a DISA port and 
require some automated digit manipulation, recorded announcements and 
Authcodes for billing purposes. This feature offers the following capabilities: 


DISA Digit Insertion 

Once a DISA Director Number (DN) is accessed, the Meridian 1 
automatically inserts from 1 to 31 digits to save the caller from having to 
manually enter these digits. Dial tone is provided if the system expects to 
receive more digits from the caller in order to complete the call. If no 
additional digits are required, the call terminates automatically. 


DISA Recorded Announcement (RAN) 


A caller may be greeted with a Recorded Announcement once a DISA DN is 
accessed. The caller can begin dialing anytime during the greeting, in which 
case the greeting is stopped and the call is processed. If the Recorded 
Announcement finishes, dial tone is provided if more digits are expected from 
the caller to complete the call. As with the case of DISA Digit Insertion, the 
call terminates automatically if no additional digits are required. 


Authcode Last Retry 

For an Authcode last request call, if a caller enters an authorization code 
(Authcode) that is invalid, the caller is prompted to enter an Authcode again. 
The reprompt for the Authcode takes the form of either an Authcode Last 
Request dial tone or a RAN before the Authcode Last Request dial tone. 


If configured, the RAN indicates to the caller that a wrong Authcode has been 
entered. While RAN is being given, all dialed digits are ignored. 


If a caller realizes they have misdialed, an octothorpe (#) can be pressed 
which allows the user to immediately re-enter the Authcode. If an invalid 
Authcode is entered for a second time, the existing invalid Authcode 
treatment results. 
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Operating parameters 


DISA Digit Insertion, DISA RAN, and Authcode Last Retry can be activated 
individually or can be combined to work in conjunction with one another. 


ISA Digit Insertion and DISA RAN can be optionally assigned on a per DISA 
basis in LD 24, and are only applicable to DISA calls. 


Authcode Last Retry can be optionally assigned on a per customer basis in LD 
88, and is applicable to all call types supporting Authcode Last. 


All existing DISA limitations apply to the DISA Digit Insertion and DISA 
RAN functionalities. 


All existing RAN limitations apply tot he DISA RAN and Authcode Last 
Retry functionality. 


All existing Authcode Last limitations apply to the Authcode Last Retry 
functionality. 


To support DISA RAN and the Authcode Last Retry RAN function, the 
Meridian | must be equipped with all the necessary RAN hardware. 


Feature interactions 
Attendant Console Operation Authcode Last Retry Not Configured 


If an invalid Authcode is entered by an attendant, overflow tone is given as 
soon as a sufficient number of Authcode digits has been entered. If the 
attendant enters some digits from an Authcode that is less than the number of 
digits defined in LD 88, silence is heard. 


Authcode Last Retry Configured 


If the caller is an attendant and the Authcode entered is invalid, once a 
sufficient number of digits has been entered, the Authcode Last Request dial 
tone is immediately given to reprompt for the Authcode. If the attendant 
enters some digits for an Authcode that is less than the number of digits 
defined in LD 88, silence is heard. Since there is no interdigit time out for an 
Attendant Console, no Authcode Last Request dial tone will be given for 
retry. 
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Authcode Last Request tone will be heard immediately prompting for 
Authcode Retry if the attendant enters some digits and an octothorpe “#’. 


Autodial If Autodial is programmed with a valid Authcode for Authcode 
Last followed by an octothorpe “#’, the existing Authcode Last operation will 
reject the Authcode as an invalid Authcode. If Authcode Last Retry is 
defined, the caller will be reprompted for the Authcode. 


Call Detail Recording (CDR) Digits inserted by DISA Digit Insertion are 
reflected in the CDR record. 


When a caller is reprompted for an Authcode due to Authcode Last Retry, and 
anew Authcode is entered, the second Authcode will overwrite the first entry. 
Therefore, the CDR record only reflects the last Authcode entered. 


Pretranslation Digits automatically inserted by DISA Digit Insertion are 
pretranslated during call processing in the same manner s if the caller had 
manually dialed the digits. 


Speed Call Ifa Speed Call entry is programmed with a valid Authcode for 
Authcode Last followed by an octothorpe “#’, the existing Authcode Last 
operation will reject the Authcode as an invalid Authcode. If Authcode Last 
Retry is defined, the caller will be reprompted for the Authcode. 


Feature packaging 
This feature is packaged under Direct Private Network Access (DPNA) 
package 250. 


DISA Digit Insertion requires the following additional package: 


— Direct Inward system Access (DISA) package 22. 


DUSA RAN requires the following additional packages: 
— Direct Inward system Access (DISA) package 22, and 
— Recorded Announcement (RAN) package 7. 
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Authcode Last Retry requires the following additional packages: 
— Basic Authorization Code (BAUT) package 25 
— Network Authorization Code (NAUT) package 63, and 


— Recorded Announcement (RAN) package 7 when an Authcode Last 
Retry RAN is required. 


Feature implementation 
DISA DN Data Configure RAN routes (LD 16) and RAN trunks (LD 14) as 
per existing procedures. 


LD 24—Respond as follows. 


NEW CHG New, or change. 
DIS DISA data. 


0-99 Customer Number. 


Route number for DISA RAN. The valid range of a 
route number for Option 11 is 0-127. 


Removes and deactivates DISA RAN> 


The maximum amount of time (in seconds) that a 
caller can wait for an available RAN trunk before being 
removed from the RAN queue and proceeding as if 
DISA RAN has been completed. 


Removes and deactivates the timer. 


Digits for DISA Digit Insertion. Up to 31 digits can be 
defined. 


Removes and deactivates DISA Digit Insertion. 
Dial tone needed after digit insertion. 


Dial tone not needed after digit insertion. 
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Authcode Data Configure RAN routes (LD16) and RAN trunks (LD 14) as 
per existing procedures. 


LD 88—Respond to the following prompts. 
NEW,CHG New, or change. 


AUB Authcode data. 


0-99 Customer Number. 


Route number for Authcode Last Retry RAN. 


Disable Authcode Last Retry. 
Enable Authcode Last Retry. 


Route number for Authcode Last Retry RAN. The valid 
range of a route number for Option 11 is 0-127. 


Removes and deactivates Authcode Last Retry RAN. 


Class code value assigned to authcode. 





Feature operation 


Operational Sequence of a DISA Call (Part 1 of 2) 


Step User Action 


Dials DISA DN. If DISA Security Access Code is required, special dial tone is 
given, and the caller continues to Step 2. Otherwise the caller 
skips to Step 3. 


Enters the Security The dial tone is removed as soon as the first digit is dialed. If 


Access Code the security access code entered is valid, the caller continues 
to Step 3. Otherwise, the existing treatment for invalid 
Security Access code is given when the interdigit timer 
expires. 


<no user action> If Authcode is required, normal dial tone is given, and the 
caller continues to Step 4. Otherwise, the caller skips to 
Step 5. 
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Operational Sequence of a DISA Call (Part 2 of 2) 


User Action 


Enters an Authcode. 


<no user action> 


<no user action> 


a) The caller listens 
to the RAN greeting; 
or 


b) begins dialing 
before the RAN is 
finished 


<no user action> 


Dials digits to 
originate the call 


Result 


The dial tone is removed as soon as the first digit is dialed. If 
the Authcode entered is valid, the caller continues to Step 5. 
Otherwise, the existing invalid Authcode treatment is given 
when the interdigit timers times out. 


If DISA Digit Insertion is not configured, the caller 
immediately continues to Step 6. Otherwise, the digits defined 
for DISA Digit Insertion are automatically inserted into the call 
register before the caller continues to Step 6. 


If DISA RAN is configured, a RAN greeting is provided, and 
the caller continues to Step 7. Otherwise, the caller skips to 
Step 8. 


a) If DISA Digit Insertion is not defined, or DISA Digit Insertion 


specifies to give dial tone to prompt the caller to enter more 
digits, the caller continues to Step 8. Otherwise, the inserted 
digits are immediately processed for call completion. 


b) The RAN greeting is stopped as soon as the first digit is 
dialed. The dialed digits are appended into the call register 
(i.e., if DISA Digit Insertion is defined, the dialed digits are 
stored after the inserted digits), and the call is processed for 
call completion. 


Dial tone is given and the caller continues to Step 9. 


Dial tone is removed as soon as the first digit is dialed. The 
dialed digits are appended into the call register (i.e., if DISA 
Digit Insertion is defined, the dialed digits are stored after the 
inserted digits), and the call is processed for call completion. 
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Step 


Feature description 


Operational Sequence of Authcode Last (Part 1 of 2) 


User Action 


Makes an outgoing 
call that requires 
Authcode Lase. 


Dials one of the 
following 


a) A valid Authcode. 


b) An invalid 
Authcode followed 
by “#” 


c) An invalid 
Authcode 


Result 


Authcode Last Request dial tone is given. If Authcode Last 
RAN is defined, RAN precedes the dial tone. The caller 
continues to Step 2. 


The Authcode Last Request dial tone is removed as soon as 
the first digit is dialed. Then depending on the digit input, one 
of the following occurs: 


a) The call is processed for call termination. 


b) If Authcode Last Retry is defined, Authcode Last Request 
dial tone is immediately given (if Authcode Last Retry RAN is 
defined RAN precedes the dial tone), and the caller continues 
to Step 3. 


If Authcode Last Retry is not defined, when the interdigit timer 
expires the existing invalid Authcode treatment is given. 


c) If Authcode Last Retry is defined: 


— Ifthe caller is an attendant, Authcode Last Request dial 
tone is immediately given (if Authcode Last Retry RAN is 
defined RAN precedes the dial tone), and the caller 
continues to Step 3. 


If the caller is not an attendant, when the interdigit timer 

expires Authcode Last Request dial tone is again given (if 
Authcode Last Retry RAN is defined RAN precedes the 

dial tone), and the caller continues to Step 3. 


If Authcode Last Retry is not defined, when the interdigit timer 
times out the existing invalid Authcode treatment is given. 





553-2751-103 Standard 6.00 October 1997 


Feature description Page 25 of 78 
Operational Sequence of Authcode Last (Part 2 of 2) 


Step User Action Result 


dials one of the The Authcode Last Request dial tone is removed as soon as 
following the first digit is dialed. Then depending on the digit input, one 
of the following occurs: 


a) A valid Authcode a) The call is processed for call termination. 


b) An invalid b) When the interdigit timer times out, the existing invalid 
Authcode followed Authcode treatment is given. 
by “#” 


c) An invalid c) When the interdigit timer times out, the existing invalid 
Authcode. Authcode treatment is given. 
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Feature description 


Electronic Lock Network Wide/Electronic Lock on Private 


Lines 


The basic Electronic Lock feature has been enhanced to provide the following 
capabilities: 


— The feature can be implemented network wide. 


— Anew Class of Service, Controlled Network Class of Service (CNCS) 
can be selected in the Customer Data Block (LD 15). 


— Locking can be implemented for Private DNs. 


In a Meridian Customer Defined Network (MCDN) environment, Electronic 
Lock Network Wide can be used to change the Class of Service of a set in a 
remote location. Electronic Lock Network Wide is activated or deactivated 
from any node by dialing the electronic Lock Flexible Feature Code (FFC), a 
password, a location code, and the DN of the set to be changed. Since the 
password length defined at the destination node is not known at the 
originating node, the Station Control Password (SCPW) length (defined in 
LD 15) must be defined the same for all network nodes. 


If the originating node has the FFC Confirmation Tone option selected, a 
confirmation tone is given when the feature is successfully activated or 
deactivated. Overflow tone is given if the operation is unsuccessful. There is 
no FFC verify code for Electronic Lock. 


When a locked set makes an outgoing trunk call, if Controlled Network Class 
of Service is defined, the Network Class of Service (NCOS) defined by 
CNCS is used instead of the NCOS defined in LD 10 or 11 for the set. If 
network signaling is configured for the trunk that normally transmits the 
NCOS of the set between electronic Switched Network (ESN) nodes, the 
CNCS is transmitted instead of the NCOS. This prevents a locked set from 
reaching the exchange network by tandeming through a TIE trunk using ESN. 
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A new prompt (PELK) is introduced in the Customer Data Block to 
implement electronic Lock on private lines. If this option is enabled, an 
outgoing call on a private line of a locked set is subject to the same restrictions 
as all other DNs on the set. The same intercept treatment would be given as 
for a regular DN. The restrictions for private lines, as well as other DN keys 
on the set, are controlled by the Controlled Class of Service (CCOS), and by 
the CNCS if defined. Therefore, for outgoing calls, the Class of Service 
restrictions and/or New Flexible Code Restriction (NFCR) apply to private 
line keys on locked sets. Only outgoing calls are affected. The Class of 
Service of anon-locked set has no affect on private lines. 


Operating parameters 
The Network Dialing Plan must be either a coordinated Dialing Plan (CDP) 
or a Uniform Dialing Plan (UDP). 


The set password lengths must be equal for all nodes in the network. 
Network wide operation is only supported through an MCDN ISDN network. 


The Electronic Lock feature must be equipped on both originating and remote 
nodes. 


The FFC used is defined on the node from which Network Electronic Lock is 
being activated. To activate or deactivate Network Electronic Lock from any 
remote node, the user has to use the FFC Electronic Lock Activate (ELKA) 
or Electronic Lock Deactivate (ELKD) code defined on that remote node. 


ISDN Basic Rate Interface (BRI) sets cannot be used to lock another set, nor 
can they be locked themselves. 


A PBX (2500/500) set with a private line DN or a BCS set with a private line 
on the Prime DN cannot be locked. 


The following hardware is required: 


— Primary Rate Interface—D-channel Handler Interface 
(DCHI)/Multipurpose Serial Data Link (MSDL) and PRI/PRI12 cards. 


— Integrated Services Digital Network Signaling Link (ISL)—DCHI cards 
and TIE trunks. 


— Virtual Network Services (VNS)—DCHI cards and any trunks. 
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Feature description 


Feature interactions 
Automatic Call distribution (ACD) An ACD set cannot be locked. 


Call Forward (CFW) Call Forward No Answer (CFNA) For Call 
Forwarding, the COS and NCOS used for the forwarding call can be taken 
from either the forwarding set or from the forwarded set, depending on the 
option defined in the Customer Data Block. 


For example, set B call forwards all calls to an external trunk. Set A calls set 
B. If OPT = CFF in LD 15 (Call Forward forwarded to party’s COS and 
NCOS), the COS and NCOS of set B are used for forwarding the call to the 
trunk. If OPT = CFO (Call Forward originating party’s COS and NCOS), the 
COS and NCOS of set A are used for forwarding the call to the trunk. 


Direct Inward System Access (DISA) The Electronic Lock feature Cannot 
be activated or deactivated when accessing the node through DISA. 


Digital Private Network Signaling System (DPNSS1) Digital Access 
Signalling system (DASS2) Analog Private Network Signalling System 
(APNSS) Electronic Lock Network Wide is not supported on DPNSS1, 
DASS2, or APNSS trunks. 


Electronic Switched Network Authcode If a station user enters an 
authcode on the set, regardless of the status of the set being locked or not, the 
NCOS defined for the authcode is used. The ESN Authcode feature overrides 
the Electronic Lock Network Wide feature. 


Flexible Numbering Plan If a network is equipped with a flexible 
numbering plan (i.e., not all the network DNs are the same length), handing 
up before the usual end-of-dialing timeout cancels the request for activation 
or deactivation of Electronic Lock. Dialing an octothorpe (#) after the 
network DN will cause the request for activation or deactivation of the 
electronic Lock to be sent immediately, instead of waiting for the usual 
end-of-dialing timeout to send it. 


Multiple Appearance DN The same locked or unlocked state applies to all 
Terminal Numbers with the same primary DN and the same SCPW. Terminal 
Numbers with the same DN, but not having the same SCPW, cannot be 
locked or unlocked. 
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New Flexible code Restriction (NFCR) With NFCR, toll denied stations 
are allowed or denied calling privileges according to the Facility Restriction 
Level (FRL) assigned to the NCOS defined in the protected line block. For a 
locked set, NCFR uses the FRL assigned to the CNCS to determine its calling 
privileges if one is defined; if no CNCS is defined, the NCOS of the locked 
set will be used. 


Scheduled Access Restrictions (SAR) 
The SAR feature overrides Electronic Lock. 


Virtual Network Services (VNS) Electronic Lock can function in a VNS 
environment. 


Feature packaging 


Electronic Lock Network Wide/Electronic Lock on Private Lines is packaged 
under Flexible Feature Codes (FFC) package 139. 


Use of this feature requires the following additional packages: 
— Controlled Class of Service (CCOS) package 81 

— Network Class of Service (NCOS) package 32, and 

— Integrated Services Digital Network (ISDN) package 145. 
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LD 15—Respond to 


Feature implementation 

Electronic Lock Network Wide/Electronic Lock on Private Lines is 
configured in the same way as Electronic Lock (currently described in the 
Flexible Feature Codes module of this document), except for the inclusion of 
the CNCS prompt in LD 15. In addition, to implement Electronic Lock on 
Private Lines, prompt PELK must be set to YES. 


the CNCS prompt as follows: 


NEW CHG New or change. 


CDB Customer Data Block. 


YES 


XXXX 


Change CCOS options. 


Special Prefix number. 


(UNR),CUN,CTD,TLD, Controlled Class of Service. 
SRE,FRE,FR1,FR2 


(X) 0-99 Controlled NCOS. 


(NO) YES Electronic Lock on Private Lines. 


(0)-8 Station Control Password length. 





Feature operation 

Electronic Lock Network Wide N ISDN network is set up connecting 
Node 1 to Node 2. Set A is the Controlling set. Set B is the set to be locked 
and unlocked by Set A. The digits that set A would dial to ring set B are to be 
in the format of a CDP or UDP dialing plan. This is standard dialing for ISDN 
features. 


To lock set B (in Node 1) from set A (in Node 2), the user goes off-hook and 
dials the electronic Lock Activate (ELKA) FFC defined in the Customer Data 
Block of Node 1, followed by the Station Password (SCPW) defined for set 
B, and the digits that set A would normally dial to ring set B (e.g., 41 + 9999 
+ 6-343-3000). If the FFCT option is configured as YES in LD 57 in the 
Customer Data Block of Node 1, confirmation tone is given to set A to 
confirm that the lock operation has been successful. Set B becomes locked if 
it was previously in an unlocked state. 
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If set B was already locked, the above operation is ignored and Set B remains 
locked; however, a confirmation tone is provided to verify that the set is 
locked. 


If the lock operation was unsuccessful, overflow tone is given. 


To unlock set B (in Node 1) from set A (in Node 2), the user goes off-hook 
and dials the Electronic Lock Deactivate (ELKD) FFC defined in the 
Customer Data Block of Node 1, followed by the SCPW defined for set B and 
the digits that set A would normally dial to ring set B (e.g., 42 + 9999 + 
6-343-3000). If the FFCT option is configured as YES in LD 57 in the 
Customer Data Block of Node 1, confirmation tone is given to set A to 
confirm that the unlock operation has been successful. Set B becomes 
unlocked it is was previously in a locked state. 


If Set B was already unlocked, the above operation is ignored and Station B 
remains unlocked; however, a confirmation tone is provided to verify that the 
set is unlocked. 


If the unlock operation was unsuccessful, overflow tone is given. 


Electronic Lock on Private Lines Feature operation of Electronic Lock 
for Private Lines is the same as for the basic Electronic Lock feature. 


Controlled Network Class of Service No specific operating instructions 
are required to use Controlled Network Class of Service. 


Three-Wire Analog Trunk - Commonwealth of Independent 
States (CIS) 


The Three Wire Analog Trunk - Commonwealth of Independent States (CIS) 
feature provides the connectivity between the Meridian 1 and the three-wire 
analog trunks (3WT) used in the CIS. Analog incoming local three-wire 
trunks, analog incoming toll three-wire trunks, and analog outgoing Direct 
Inward Dialing (DID) three-wire trunks can be connected to the Meridian 1. 
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The following hardware cards are supported: 


— Cards supported in an Enhanced Peripheral Equipment (EPE) 
environment are referred to as E3W cards. They consist of: 


e APC661 for incoming trunk calls. 
e  QPC661 for incoming toll calls. 
e  QPC661 for outgoing 3WT local trunks. 


— Cards supported in an Intelligent Peripheral Equipment (IPE) 
environment are referred to as X3W cards. They consist of: 


e NTS5K60AA for incoming local and toll trunks 
e NTS5K61AA for outgoing trunks. 


The following functions are provided by the Three-Wire Analog Trunk - CIS 
feature: 


— Delivery of Automatic Number Identification (ANI) on request from the 
Public Exchange/Central Office for outgoing 3WT analog calls 


— Downloading of specific transmission parameters (i.e., pad data, public 
network toll access code, and hardware ID) for X3W cards, and 


— Provision of dial tone internally by the Meridian 1 to the originator of the 
call after seizure of an outgoing X3W trunk. 


The trunk state change validation timing is performed by the 3WT cards. For 
2WT trunks, the originating party controls the disconnection of a call. When 
the originating party goes on-hook, the call is released. Note however, that 
when Malicious Call Trace is enabled, the Local Exchange may require a 
two-way release. This two-way release applies only on a set. 


A 3WT Unproductive Timer is used to prevent a call on a X3W trunk from 
remaining unanswered for too long. This timer can be set to a maximum of 
10 minutes. 


For outgoing calls, digits are sent from the main Central Processing Unit 
(CPU) to the 2WT firmware. This is done by Dual-tone Multifrequency 

(DTMF) signaling for E3W equipment, and by IPE messaging for X3W 

equipment. The firmware then sends the digits as pulses and controls the 
actual decadic outpulsing. 
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Digits for incoming calls are received by the 3WT firmware as pulses. For 
E3W equipment, each valid pulse is reported to the main CPU by Scan and 
Signaling Distributor (SSD) messages. For X3W equipment, the pulses are 
collected by firmware and complete digits are reported to the CPU as IPE 
digit messages. 


Operating parameters 


X3W trunk cards can only be configured on IPE shelves; E3W trunk cards 
can only be configured on EPE shelves. 


Trunk-to-trunk connections are supported, but the ANI information will refer 
to the ANI DN of the incoming route, except with QSIG, Q931, and Digital 
Private Signaling System #1 (DPNSS1) routes. QSIG, and Q931 ANI 
information will use the Calling Line Identification (CLID) information, 
whereas DPNSS1 ANI will use the Originating Line Identifier (OLT) 
information if this information is present. 


The Dynamic Loss Switching feature is not supported, because there is no 
connection matrix and loss alternative table available for the CID market. 
However, Dynamic Loss Switching is supported in Australia, New Zealand, 
Italy, and China. 


The static Loss Plan Download (SLPD) feature is supported on X3W trunks. 
No loss downloading/switching is done for E3W trunks. 
ANI is only supported for outgoing calls. 


The data in ANI is built only once at the beginning of the call. Once the trunk 
access code is dialed, the ANI information is downloaded to the 3WT 
firmware. The download of ANI occurs only once and is not changed or 
redownloaded for any kind of operation during a call; therefore, if the call 
goes through any type of modification such as a transfer or call forward for 
instance, the ANI information sent when requested is that of the original 
originator of the call. 


Toll Operator Manual Ringing and Break-In are not supported on IPE analog 
trunks. 
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Feature description 


Data calls are supported, but with the limitations due to the 500 Hz ANI 
requests that can happen any time during the call and the ANI information 
being sent of the same voice circuit on which the data is being transmitted; 
therefore, the transmission of data is not guaranteed. 


Multifrequency Shuttle signaling is not supported on either X3W or E3W 
trunk cards. 


EPE interfaces cannot be used on the Option 11. 
The CIS A-law XCT (NTD17AE) is required. 


Feature interactions 

Authorization Code An extension may, referring to the Authorization 
Code, seize an outgoing CIS 3WT trunk. The Authorization Code category is 
used to build the ANI message, meaning that a set which has a CIS restricting 
call category can complete a call to the public network using the 
Authorization Code. 


Autodial Autodial on a E3W trunk will fail for toll calls. The reason is that 
E3W trunks do not wait for the ANI request from the Public 
Exchange/Central Office, which is expected to appear after the toll access 
code is dialed. The Public Exchange then does not accept the call due to 
failure to receive ANI information. 


Dial Tone Detection Dial Tone detectors are supported with the limitations 
of the reliability of the tone provided by the Public Exchange. 


DPNSS1 Gateway The ANI information transmitted for this incoming 
DPNSS1 route will include the Local Exchange Code (LEC) of the CIS 
outgoing route, the ANI DN, and the Category Code (CAC) of this incoming 
route. 
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The ANI DN information which is built will refer to the Originating Line 
Identifier (OLI) if present and the Route DN Length prompt for ANI (RDNL 
0) in LD 16. If the OLI is available, but RDNL = 0 for that route, the ANI DN 
is the ANI DN of that incoming route. If the OLI is available, but RDNL = 0 
and the ANI DN of the incoming route is not defined, the ANI DN is the ANI 
DN of the CIS outgoing route. If the OLI is available, but RDNL = 0, and the 
ANI DN of the incoming route is not defined, and the ANI DN of the CIS 
outgoing route is not defined, the ANI DN will be built with the Additional 
Digit (ADDG). If RDNL 0, its value will be the number of digits extracted 
from the OLI to be used as the ANI DN. The least significant digit of the OLI 
will be extracted (e.g., if the DN is 4201, the 1 is the least significant digit). 


If there is no OLI, the ANI DN of the SPNSS1 route is used to build the ANI 
message. If there is no ANI DN on the DPNSS1 route, the ANI DN of the CIS 
outgoing route is used to build the ANI message. If there is no ANI DN on 
the CIS outgoing route, the ANI is built with the ADDGs of the CIS route 
(ADDG is always defined). 


Incoming Digit Conversion The construction of an ANI message does not 
care if Incoming Digits Conversion is used. THe DN sent as ANI is the actual 
DN of the set, not necessarily the DID number of dial to reach the set. 
Therefore, if an external party uses a DN for making a call to the 
corresponding extension which is delivered in an ANI message, the call may 
fail. 


Last Number Redial Last Number Redial on an E3W trunk will fail for toll 
calls. The reason is that E3W trunks doe not wait for the ANI request from 
the Public Exchange, that is expected to appear after the toll access code is 
dialed. The Public Exchange will not accept the call due to the failure to 
receive ANI information. 


Multiple Appearance DNs Since the ANI category is defined on a per set 
basis, two stations with the same multiple Appearance DN can be assigned 
different ANI categories. 


Q931 Gateway/BR1 Gateway The ANI information transmitted for this 
incoming Q931 route will include the LEC of the CIS outgoing route, the ANI 
DN, and the CAC of this incoming route. 


Basic and Network Authorization Code Description 


Page 36 of 78 


Feature description 


The ANI DN information which is built will refer to the Calling Line 
Identification (CLID) if present and the Route DN Length prompt for ANI 
(RDNL 0) in LD 16. If the CLID is available but RDNL = 0 for that route, the 
ANI DN is the ANI DN of that incoming route. If the CLID is available, but 
RDNL =0, and the ANI DN of the incoming route is not defined, the ANI DN 
is the ANI DN of the CIS outgoing route. If the CLID is available, but RDNL 
= 0, and the ANI DN of the incoming route is not defined, and the ANI DN 
of the CIS outgoing route is not defined, the ANI DN will be built with the 
ADDG. If RDNL 0), its value will be the number of digits extracted from the 
CLID to be used as the ANI DN. The least significant digits of the CLID will 
be extracted (e.g., if the DN is 4201, the 1 is the least significant digit). 


If there is no CLID, the ANI DN of the Q931 route is used to build the ANI 
message. If there is no ANI DN on the Q931 route, the ANI DN of the CIS 
outgoing route is used to build the ANI message. If there is no ANI DN on 
the CIS outgoing route, the ANI is built with the ADDG of the CIS outgoing 
route (ADDG is always defined). 


QSIG Gateway The ANI information transmitted for this incoming QSIG 
route will include the LEC of the CIS outgoing route, the ANI DN, and the 
CAC of this incoming route. 


The ANI DN information which is built will refer to the Calling Line 
Identification (CLID) if present and the Route DN Length prompt for ANI 
(RDNL 0) in LD 16. If the CLID is available but RDNL = 0 for that route, the 
ANI DN is the ANI DN of that incoming route. If the CLID is available, but 
RDNL =0, and the ANI DN of the incoming route is not defined, the ANI DN 
is the ANI DN of the CIS outgoing route. If the CLID is available, but RDNL 
= 0, and the ANI DN of the incoming route is not defined, and the ANI DN 
of the CIS outgoing route is not defined, the ANI DN will be built with the 
ADDG. If RDNL 0), its value will be the number of digits extracted from the 
CLID to be used as the ANI DN. The least significant digits of the CLID will 
be extracted (e.g., if the DN is 4201, the 1 is the least significant digit). 


If there is no CLID, the ANI DN of the QSIG route is used to build the ANI 
message. If there is no ANI DN on the QSIG route, the ANI DN of the CID 
outgoing route is used to build the ANI message. If there is no ANI DN of the 
CIS outgoing route, the ANI is built with the ADDG digits of the CIS 
outgoing route (ADDG is always defined). 
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The ANI information transmitted for this incoming QSIG route will include 
the LEC of the CIS outgoing route, the ANI DN, and the CAC of this 
incoming route. 


R2MFC Calling Number Identification The incoming R2MFC CNI will 
not be tandemed if the call is outgoing to a CIS trunk. The ANI built will be 
the LEC of the outgoing CIS route, the ANI DN of this R2MFC incoming 
route if defined (otherwise it will be the ANI DN of the outgoing CIS route, 
or the ADDG digit), and the CAC of the incoming R2MFC route. 


The category (CAC) used to build and the R2MFC Calling Number 
Identification (CNI) for the analog, digital and Basic Rate Interface (BRI) sets 
is used to build the CIS ANI. The meaning of CAC is different between the 
R2MEFC CNI signaling and the CIS signaling (analog BRI, and digital). 
R2MFC CAC prompt values are in the range of 0 to 10, and the default is 0. 
CIS CAC prompt values are in the range of 0 to 9, and the default value is 3. 


If the MFC package is equipped, but not the CIST package, the CAC prompt 
uses the R2MFC range and default. If the CIST package is equipped (MFC 
package equipped or not), the CAC prompt uses the CIS range and default. 


Speed Call Speed Call of the E3W trunk will fail for roll calls. E3W trunks 
do not wait for the ANI request from the Public Exchange, that is expected to 
appear after the toll access code is dialed. The Public Exchange will not 
accept the call due to the failure to receive ANI information. 


Virtual Network Services Virtual Network Services is not supported on 
CIS trunks. 


Feature packaging 
The Three-Wire Analog Trunk - CIS feature is contained in Commonwealth 
of Independent States Trunk Interface (CIST) package 221. 


The following packages are also required to implement this feature: 
— Fast Tone and Digit Switch (FTDS) package 87 (only for E3W cards) 
— Flexible Tones and Cadences (FTC) package 125 


— International supplementary Features (SUPP) package 131 for 
DID/DOD 


— Flexible Numbering Plan (FNP) package 160 
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— Trunk Failure Monitor (TFM) package 182, and 


— Meridian 1 Extended Peripheral Equipment (XPE) package 203 (only for 
X3W cards). 


Feature implementation 

This is an example that describes how the 3WT related features are 
configured. Only the prompts that are significant for the Three-Wire Analog 
Trunk - CIS feature are mentioned. 


The following features are needed to make the feature work according to this 
example: B34 Codec Static Loss Plan Downloading; Partial Dial Timer; 
End-of-Selection Busy; Tone to-Last Party; Special Dial Tones After Dialed 
Numbers; Trunk Barring, and Special Service List. 


LD 17—Configure the system data. 


NEW CHG Add or Change. 


Change system parameters. 


System Pulse Code Modulation companding law. 
A-law is used to the CIS market. 


Dual-tone Multifrequency burst and interdigit pause for 
the Tone and Digit Switch. Pulse/Pause Ration 70/70. 
For outgoing E3W cards, the preferable digitone burst 
time is 70 ms. 
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LD 16—Configure an incoming X3W DID route. (Part 1 of 2) 


NEW CHG 
RDB 


YES 
ICF 0 


OGF 0 


EOD 13952 
DSI 11904 
DDL 0 


Add, or change.] 


Route Data Block. 


Direct Inward Dialing trunk data block. 


This is not a digital trunk route. 


Incoming trunk. 


Change control or timers. 


Incoming flash timer should be set to 0. Validation is 
performed by 3WT firmware. 


Outgoing flash timer should be set to 0. Validation has 
already been done by 3WT firmware. 


End of dial timer, default value in milliseconds. 
Disconnect supervision timer in milliseconds. 


Delay Dial Timer not needed. 


Near End Disconnect Control. Originating end control. 


Meridian 1 is not the controlling party on incoming 
calls. 
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LD 16—Configure an incoming X3W DID route. (Part 2 of 2) 


This is not an outpulsing route. 
Partial dial timing is equipped using EOD. 
Busy signal is sent on time-out. 


Number of digits expected on DID routes. 0, the 
default, indicates no fixed value. This value must be 
defined according to the numbering plan. 


Busy Tone Time. Length of Busy/overflow to be 
returned on DID routes in seconds. 


0-(3)-9 Route ANI category. 
0-9999999 Route ANI DN. 


0-(4)-7 Route DN Length for ANI. This is printed for DPNSS1, 
MCDN, and QSIG routes only. 
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LD 16—Configure an outgoing X3W DID route and define the toll digit using the TDG prompt. 


(Part 1 of 2) 


NEW CHG 
RDB 


YES 
ICF 0 


OGF 0 


EOD 13952 
DSI 11904 
DDL 0 
GTO 2944 


Add, or change. 


Route Data Block. 


direct Inward Dialing trunk data block. 


This is not a digital trunk route. 


Outgoing trunk. 


Change control or timers. 


Incoming flash timer should be set to 0 in milliseconds. 
Validation will be done by 3WT firmware. 


Outgoing flash timer should be set to 0 in milliseconds. 
Validation will be done by 3WT firmware. 


End of dial timer, default value. 
Disconnect supervision timer. 


Delay Dial Timer not needed. 


Outgoing guard timer. 


Near End Disconnect Control Either end control. 


Far End Disconnect Control Either end control. 


North American Toll scheme. 


Toll Digits. List of digits after trunk access code which 
indicate toll calls. 
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LD 16—Configure an outgoing X3W DID route and define the toll digit using the TDG prompt. 
(Part 2 of 2) 


This is not an outpulsing route. 


Seizure acknowledge signal is not expected. 


0-9999999 Local Exchange Code. A value must be entered. 


0-(8)-9 Additional digit. 


0-(3)-9 Route ANI category. 
0-9999999 Route ANI DN. 


0-(4)-7 Route DN Length for ANI. This is printed for DPNSS1, 
MCDN, and QSIG routes only. 
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LD 18—Configure the Special Service List. 
NEW CHG Add, or change. 
SSL Special Service List data block. 
0-99 Customer number. 


1-15 List number for Special Service List. 


XXXX Special Service Digit or Digits (1 to 4 digits). 


The SSDG entry is a toll number. 


Special Service Digit or Digits (1 to 4 digits). 


The SSDG entry is a Special Service unanswered call. 





LD 16—Configure an outgoing X3W DID route and define the toll access code using the SSL 
prompt. (Part 1 of 3) 


NEW, CHNG Add, or change. 
RDB Route Data Block. 


Direct Inward Dialing trunk data block. 


This is not a digital trunk route. 


Incoming trunk. 





Change control or timers. 
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LD 16—Configure an outgoing X3W DID route and define the toll access code using the SSL 
prompt. (Part 2 of 3) 


- TIMR ICF O Incoming flash timer should be set to 0. Validation has 
already been done by 3WT firmware. 


- TIMR OGF 0 Outgoing flash timer should be set to 0. Validation has 
already been done by 3WT firmware. 


- TIMR EOD 13952 End of dial timer, default value. 
- TIMR DSI 11904 Disconnect supervision timer. 
- TIMR DDL 0 Delay Dial Timer not needed. 


Near End Disconnect Control Originating end control. 
Far End Disconnect Control Originating end control. 


Meridian 1 is not the controlling party on incoming 
calls. 


This is not an outpulsing route. 


Partial dial timing is equipped using EOD. 


End of selection and busy signals enabled. 


Number of digits expected on DID routes. 0, the 
default, indicates no fixed value. This value must be 
defined according to the numbering plan. 


Length of busy/overflow tone to be returned on DID 
routes in seconds. 
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LD 16—Configure an outgoing X3W DID route and define the toll access code using the SSL 
prompt. (Part 3 of 3) 


Route ANI category. 


Route ANI DN. 


Route DN Length for ANI. This is printed for DPNSS1, 
MCDN, and QSIG routes only. 





LD 16—Configure an outgoing E3W COT route. (Part 1 of 2) 


NEW CHG Add, or change. 
RDB Route Data Block. 


Central Office Trunk data block. 


This is not a digital trunk route. 


Outgoing trunk. 


YES Change control or timers. 


ICF O Incoming flash timer should be set to 0 in milliseconds. 
Validation will be done by 3WT firmware. 


OGF 0 Outgoing flash timer should be set to 0 in milliseconds. 
Validation will be done by 3WT firmware. 


EOD 13952 End of dial timer, default value. 
DSI 11904 Disconnect supervision timer. 
DDL 0 Delay Dial Timer not needed. 
GTO 2944 Outgoing Guard Timer. 
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LD 16—Configure an outgoing E3W COT route. (Part 2 of 2) 


Near End Disconnect Control Either end control. 
Far End Disconnect Control Either end control. 


Meridian 1 is not the controlling party on incoming 
calls. 


North American Toll scheme. 


0-9999999 Local Exchange Code. 
0-(8)-9 Additional digit. 
0-(3)-9 Route ANI category. 
0-9999999 Route ANI DN. 


0-(4)-7 Route DN Length for ANI. This is printed for DPNSS1, 
MCDN, and QSIG routes only. 
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LD 14—Add or change trunk data for X3W incoming DID trunk. 


NEW CHG Add, or change. 
DID Direct Inward Dial trunk data block. 


Extended Trunk Type. IPE DID trunk card. 


Trunk Signaling. Three-wire CIS trunk signaling. 


Prompted only for incoming routes (i.e., [COG = ICT). 
NO = Local trunk. YES = Toll trunk. 


Immediate incoming start arrangement. 


YES Answer and disconnect supervision required. 


(DIP) Dial pulse (for 3WT incoming and outgoing). 


(SHL) LOL Line length used for pad setting. 
(BARD) BARA Barring (denied) allowed. 
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LD 14—Add or change trunk data for X3W outgoing DID trunk. 


NEW CHG Add, or change. 
DID Direct Inward Dial trunk data block. 


IPE DID trunk card. 


Three-wire CIS trunk signaling. 


Immediate outgoing start arrangement. 


YES Answer and disconnect supervision required. 


(DIP) Dial pulse (for 3WT incoming and outgoing). 
(SHL) LOL Line length used for pad setting. 


(BARD) BARA Barring (denied) allowed. 
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LD 14—Add or change trunk data for E3W incoming three-wire trunk. 


NEW CHG Add, or change. 


DID Direct Inward Dialing trunk data block. 


Ear and mouth. 


Double Density. 


Immediate incoming start arrangement. 


Answer and disconnect supervision required. 


Dial pulse. 





LD 14—Add or change trunk data for E3W outgoing three-wire trunk. 


NEW CHG Add, or change. 
COT Central Office Trunk data block. 


Loop start. 


Double density. 


Answer and disconnect supervision required. 


Polarity sensitive care. 


Answer and disconnect supervision required. 


Digitone. 
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LD 10—Add or change PBX telephones for CIS. 


NEW CHG Add, or change. 


500 PBX (500/2500) telephone data block. 


(DNAA) DNAD DN of set (allowed) denied for use in ANI messages. 


0-9 Specifies ANI category for 3WT calls. 





LD 11—Add or change BSC telephones for CIS. 


NEW CHG Add, or change. 


aaaa Telephone type, where: aaaa = SL1, 2006, 2008, 
2009, 2016, 2018, 2112, 2216, 2317, 2616, or 3000. 


(DNAA) DNAD DN of set (allowed) denied for use in ANI messages. 
0-9 Specified ANI category for 3WT calls. 





LD 12—Add or change an Attendant Console for CIS. 


NEW CHG Add, or change. 


ATT Console type. 
1250 
2250 


(DNAA) DNAD DN of set (allowed) denied for use in ANI messages. 


0-9 Specifies ANI category for 3WT calls. 
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LD 27—Add or change BRI sets for CIS. 


NEW CHG Add, or change. 


DSL Digital Subscriber Loop data block. 


(DNAA) DNAD DN of set (allowed) denied for use in ANI messages. 


0-9 Specifies ANI category for 3WT calls. 





LD 56—Configure dial tone, busy tone, and tone to last party. (Part 1 of 3) 


NEW CHG PRT Add, change, or print. 
MCAD Master Cadence data block. 
30 Cadence number. In this example entry 30 is modified. 


On-off phases for cadence. 


NEW CHG PRT Add, change, or print. 
FCAD Firmware Cadence data block. 
Cadence number. In this example entry 30 is modified. 


On-off phases for cadence. 0.3 second on. 0.3 second 
off. 


Repeating cycles. 
On/off cycles to be repeated. 
Define tones associated with the cadence. 


420 Hz and - 12 dB below overload. 


NEW CHG PRT Add, change, or print. 


FTC Flexible Tones and Cadence data block. Used to 
provide special dial tone after dialed number. 
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LD 56—Configure dial tone, busy tone, and tone to last party. (Part 2 of 3) 


Hardware Controlled Cadences and Tones 
modification of the hardware. 


Busy tone. 


420 Hz and - 12 dB below overload. 


XCT cadence number. 0.3 seconds on, 0.3 seconds 
off. 


Tone to last party. 


420 Hz and - 12 dB below overload. 


XCT cadence number. 0.3 seconds on, 0.3 seconds 
off. 


Tone to last party timer in seconds. 


Source Tones. 


CIS continuous dial tone within the range. 


420 Hz and - 12 dB below overload. 


No cadence. 


NEW CHG PRT Add, change, or print. 
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LD 56—Configure dial tone, busy tone, and tone to last party. (Part 3 of 3) 


Special Dial Tone After Dialed Number data block. 


The digit 9 is to be used as an outgoing local access 


code. 


Tone to be provided after the dialed digit 9. 





LD 88—Configure the Authcode data block. 


NEW CHG Add, or change. 
AUB Authcode data block. 


Classcode value assigned to Authcode (NAUT). 


Network Class of Service Group number 


specifies ANI category for CIS calls. 
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LD 97—Configure the IPE system record for three-wire trunks. 


Change. 


Loss Plan Tables. Configure loss parameters for 
downloading. 


Install a B34 Static Los Plan Table. 
A numbered predefined table is to be used. 


2 = Austrian Table. 


Change. 


Los Plan Tables. Configure loss parameters for 
downloading. 


Install a B34 Static Loss Plan Table. 


Customize a numbered predefined table. 


Response CSTM at STYP prompt requires a PWD2 
password or a LAPW password with Loss Planning 
Customizing Allowed (LOSA) access. This prompt 
appears if the appropriate password has not been 
given previously. 


Enter loss levels for DID short line. 


Enter loss levels for DID long line. 





Feature operation 
No specific operating instructions are required to use this feature. 


553-2751-103 Standard 6.00 October 1997 


Feature description Page 55 of 78 


Authorization code administration 


Classcodes 

With the NAUT and BAUT features, a “classcode” structure is part of 
authorization code administration. A classcode is a combination of COS, 
TGAR, and NCOS codes. There can be up to 116 (0-115) classcodes defined 
through the Authorization Code Data Block (AUB, LD 88), each with a 
different combination of COS, TGAR, and NCOS codes. Authorization codes 
that have the same combination of COS, TGAR, and NCOS codes are 
assigned the same classcode. 


Creating authorization codes 

When creating new authorization codes, a classcode associated with the new 
authorization codes is specified. The new authorization codes will then be 
automatically assigned the COS, TGAR, and NCOS codes associated with 
the specified classcode. 


Note: The BAUT feature does not support automatic generation of 
authorization codes. With the NAUT feature, authorization codes can be 
defined individually by the customer or generated automatically by the 
Meridian 1. 


Exemptcode 

When an authorization code is to be removed from use, a facility exists to 
prevent that authorization code from being reused (that is, the authorization 
code will not be accepted as valid input when individually defining 
authorization codes). This is accomplished through an “exemptcode.” When 
an authorization code is removed from use, an exemptcode is assigned to the 
authorization code in place of the classcode. The exemptcode is the month 
(for example, JAN, FEB) taken from the system clock. If an exemptcode is 
not requested, the removed authorization code is returned to the pool of 
unused authorization codes and can be reused at any time. 
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Default Facility Restriction Level 

The Route List Block (RLB) program (LD 86) is used to define a minimum 
Facility Restriction Level (FRL) for each route list. This minimum FRL 
(range 0-7) is used to determine whether or not to prompt for an authorization 
code entry after a call. If a minimum FRL is not specified, the actual 
minimum FRL in the initial route set is used as a default. Similarly, the Route 
Data Block (RDB) program (LD 16) is used to define whether to prompt for 
an authorization code entry on calls on incoming or two-way tie trunk groups. 


Network Authorization Code 


The Network Authorization Code (NAUT) feature provides for up to 20,000 
authorization codes of 1 to 7 digits. 


Note: With X11 release 13 and later, the authorization codes can be of 
1 to 14 digits. 


The NAUT feature incorporates all the features of the BAUT feature, adding 
two enhancements: 


— a “conditionally last” option for entering an authorization code after 
dialing a NARS, BARS, or CDP call 


— allowing the attendant to enter an authorization code 


Authorization code conditionally last 


With the NAUT feature, users can be prompted “conditionally” for an 
authorization code after dialing a NARS, BARS, or CDP call. The prompt is 
by an “authorization code request tone,” which consists of 10 bursts of dial 
tone, followed by steady dial tone. (The authorization code request tone can, 
optionally, be preceded with an appropriate recorded announcement.) The 
user is prompted for an authorization code entry only if 


— an authorization code was not previously entered 


— the Facility Restriction Level (FRL) associated with the user’s Network 
Class of Service (NCOS) is less than the service change assigned 
minimum FRL of the route list that NARS, BARS, or CDP would use for 
the call 
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Users at a remote switch (Meridian 1 Main or Conventional Main) connected 
via tie trunks to a Meridian 1 Node can (optionally) be prompted for an 
authorization code entry after dialing a NARS, BARS, or CDP call. The user 
is prompted for an authorization code entry only if 


— an authorization code was not previously entered 


— the FRL associated with the NCOS of the incoming (or two-way) tie 
trunk is less than the minimum FRL of the route list that NARS, BARS, 
or CDP would use for the call 


— _ the route is defined in the Route Data Block (RDB), LD 16, to prompt for 
an authorization code entry on incoming NARS, BARS, or CDP calls 


Users accessing a Meridian 1 Node via the Direct Inward System Access 
(DISA) feature to make a NARS, BARS, or CDP call are prompted for an 
authorization code entry only if 


— an authorization code was not previously entered 


— the FRL of the NCOS assigned to the DISA Directory Number (DN) is 
less than the minimum FRL of the route list that NARS, BARS, or CDP 
would use for the call 


Attendant input of authorization code 


Normally, because an attendant is not restricted from accessing any system 
resource, there is no need for the attendant to have an authorization code. The 
Network Authorization Code feature enables the attendant to enter an 
authorization code for other callers. For example, the attendant can enter an 
authorization code (after dialing the SPRE and the digit “6”) and complete a 
long distance call for a local station user whose COS is toll denied (TLD). If 
the Call Detail Recording (CDR) of authorization codes is defined for the 
customer, the local station user’s authorization code digits appear in the CDR 
record for billing purposes. 


Attendants are normally assigned an NCOS having a high FRL so that they 
can make any type of call, including NARS, BARS, or CDP calls. An 
attendant can, however, be prompted for an authorization code entry if the 
FRL required to access a route list fora NARS, BARS, or CDP call is greater 
than the FRL of the attendant’s NCOS. 
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